系列：30 天打造企業級 PLM：從動態表單、簽核引擎到 Agile 資料遷移
每年收到 Agile 維護費續約單的時候，心情都很複雜。金額年年往上調，但我們對系統做的事十年如一日：開料號、發變更單、簽核、放行。系統異常？請開 SR、請顧問評估、請等報價單，通常要好幾個月才有辦法處理。
然後，2023 年 10 月，Oracle 送來了正式的分手信：
消息傳開後，第一個跳出來的不是技術問題，是老闆的問題：「要換系統嗎？要花多少錢？」
攤開選項，每一條路都讓人直冒冷汗：
要嘛付錢、要嘛付更多錢、要嘛提心吊膽。還是——
自己打造一套。
說出「自己打造一套」之前，先交代我的經歷。凱文大叔接觸 PLM 的時間比寫 Java 還久，整個工作生涯幾乎都圍著 PLM 打轉：從導入、管理到客製整合，這套系統的每個角落我都摸過。
這種資歷的優勢是我很清楚 PLM 的骨架長什麼樣。哪些功能是真正的核心、哪些是行銷簡報上的包裝；使用者每天卡在哪一步、管理員最怕動哪個設定。這些讀文件讀不來，是經年累月累積出來的。
所以「自建 PLM」這個念頭，對沒經驗的人來說失敗率非常高；對我來說，是把累積了大半輩子的 domain know-how 換一種形式寫下來，從「操作別人的系統」變成「打造自己的系統」。敢的底氣不在技術多強，在於對這個領域夠熟。技術可以邊做邊學，領域理解沒辦法速成，而 PLM 恰好是領域理解占七成的那種系統。
「自己做」聽起來很熱血，但衝動之前得先誠實回答一個問題：這十幾年來，我們到底用了 Agile 的哪些功能？於是我們把功能清單攤開來，問使用者「這功能有在用嗎」，結果如下：
| 經常使用 | 幾乎沒用過 |
|---|---|
| 料號（Item）與版本管理 | CAD 整合與 3D Viewer |
| BOM 結構與多階展開 | PPM（專案組合管理） |
| 變更單（ECR/ECO/ECN）簽核流程 | PQM（品質管理）大部分模組 |
| 附件檔案管理 | PG&C（禁用物質管理） |
| 動態擴充欄位（Detail Page） | 各種買了沒開的模組授權 |
關鍵在右邊那一欄，尤其是 Viewer。商用 PLM 授權費裡很大一塊是為 CAD 整合與 3D 視覺化買單，但很多企業的設計檔案走的是另一套系統，工程師要看圖自然會去開 CAD，從來沒有人在 PLM 裡轉過 3D 模型。PLM 這端真正的需求只有「把檔案掛在料號上、簽核時看得到、稽核時有記錄」。說白了，我們付了一整套瑞士刀的錢，實際只用了開瓶器，而且每年還在為那些沒打開過的刀片繳保養費。
把需求收斂之後，剩下的核心其實不多：
這四件事，沒有一件是做不出來的。於是這個系列的主角 Mini-PLM 誕生了。
先講結論：可行。做完之後系統長這樣：
| 項目 | 規模 |
|---|---|
| 後端 Java | 約 83,000 行 / 689 個檔案 |
| 前端 TypeScript | 約 77,000 行 / 258 個檔案 |
| 資料庫 | 84 張業務資料表（68 個 JPA Entity + 關聯表） |
技術選型先列個總覽，Day 2 起逐一展開：
還有一個十年前不存在的關鍵變數：AI Coding。這套系統的開發後期加入 AI 協作，最有感的一次，是把 Form 與流程的設定介面從傳統表格改成 Canva 式的拖拉視覺化設計器。放在以前這是要排一整季的功能，實際只花不到一周。「小團隊自建企業系統」這個命題，因為 AI 的出現，可行性和十年前完全是兩回事。
這個系列不是「30 天速成，人人都能做 PLM」的勵志文。恰恰相反，我想花 30 天講清楚的是：企業系統的難點很少落在 CRUD，真正的坑是那些沒踩過就不知道的細節。它們共同的特徵是出事的地方和真正的病灶，往往隔了十萬八千里。先預告後面幾天會展開的血淚現場：
@CreatedBy 關聯上多掛了一個 cascade，每存一次表單就把審計欄位的空殼物件 merge 回帳號表。症狀在東邊，病灶在西邊@Transactional(REQUIRES_NEW)。它開了一個新交易，自然讀不到「上一關剛簽完、還沒 commit」的紀錄。差一個註解參數，行為天差地遠，而且測試環境單步操作根本重現不了每一條都是實際發生、實際除錯、實際上線驗證過的。這些細節不會出現在任何框架的 Getting Started 裡，但它們才是「企業系統」與「範例專案」的分水嶺。
| 週次 | 主題 |
|---|---|
| 第 1 週（Day 1–5） | 技術選型、建置管線、領域模型設計、Metadata-driven、API 設計 |
| 第 2 週（Day 6–12) | JWT/LDAP 認證授權、動態表單、簽核引擎、Trigger 規則引擎與交易 |
| 第 3 週（Day 13–19） | 版本機制、BOM 演算法、Redline、進階搜尋、前端架構、SSE 即時通知 |
| 第 4 週（Day 20–22） | Playwright E2E、壓測調校、監控維運 |
| Migration（Day 23–24） | 舊系統資料遷移：策略、考古與匯出工具 |
| 進階主題（Day 25–28） | 檔案管理、批次匯入、雙資料庫支援、資安強化 |
| 收尾（Day 29–30） | 部署上線、總結與踩坑排行榜 |
Oracle Agile 的落日給了我們一個被迫重新思考的機會。當你真正盤點需求，會發現商用 PLM 裡你需要的那 50%，是一個小團隊做得出來的；而做出來的過程中埋的坑，就是這 30 天要講的故事。
明天 Day 2，從最基礎的問題開始：Monorepo 與建置管線——前後端解耦開發、單一產物打包，如何用一個 repo 管好兩個世界？
那封 Oracle 的分手信很有衝擊，2027 之後只剩 Sustaining Support、出事自己扛，聽起來真的像把核心系統推到懸崖邊；你把 Agile 十年來其實只用到料號、BOM、變更單和動態欄位這幾塊攤開來看，瑞士刀只拿開瓶器那段超有畫面。還有 AI Coding 讓原本要排一季的拖拉式設計器不到一週就長出來，這種把企業 PLM 自己做起來的路線，讀完也讓我想到自己最近在整理實作經驗。我手邊有多的 Lovable 額度想送給有緣人，有興趣可從連結看看我的系列。 https://ithelp.ithome.com.tw/articles/10401174
iThome鐵人賽
看影片追技術